home *** CD-ROM | disk | FTP | other *** search
/ Programming Languages Suite / ProgramD2.iso / Borland / Borland C++ V5.02 / DOC.PAK / PE.TXT < prev    next >
Text File  |  1997-05-06  |  45KB  |  1,254 lines
  1.  
  2.  PORTABLE EXECUTABLE FORMAT
  3.  
  4.  Author:  Micheal J. O'Leary
  5.  
  6.  
  7.  Preface
  8.  
  9.  This document was edited and released by Microsoft Developer
  10.  Support. It describes the binary portable executable format for NT.
  11.  The information is provided at this point because we feel it will
  12.  make the work of application development easier. Unfortunately, the
  13.  information in this document may change before the final release of
  14.  Windows NT. Microsoft is NOT committing to stay with these formats
  15.  by releasing this document. Questions or follow-ups for any of the
  16.  information presented here should be posted to CompuServe MSWIN32
  17.  forum, section 6.
  18.                     --Steve Firebaugh
  19.                       Microsoft Developer Support
  20.  
  21.  
  22.  
  23. Contents
  24.  
  25.  1. Overview
  26.  
  27.  2. PE Header
  28.  
  29.  3. Object Table
  30.  
  31.  4. Image Pages
  32.  
  33.  5. Exports
  34.    5.1 Export Directory Table
  35.    5.2 Export Address Table
  36.    5.3 Export Name Table Pointers
  37.    5.4 Export Ordinal Table
  38.    5.5 Export Name Table
  39.  
  40.  6. Imports
  41.    6.1 Import Directory Table
  42.    6.2 Import Lookup Table
  43.    6.3 Hint-Name Table
  44.    6.4 Import Address Table
  45.  
  46.  7. Thread Local Storage
  47.    7.1 Thread Local Storage Directory Table
  48.    7.2 Thread Local Storage CallBack Table
  49.  
  50.  8. Resources
  51.    8.1 Resource Directory Table
  52.    8.2 Resource Example
  53.  
  54.  9. Fixup Table
  55.    9.1 Fixup Block
  56.  
  57.  10. Debug Information
  58.    10.1 Debug Directory
  59.  
  60.  
  61.  
  62. 1. Overview
  63.  
  64.     ┌──────────────────┐  <──┐ <───── Base of Image Header
  65.     │ DOS 2 Compatible │     │
  66.     │    EXE Header    │     │
  67.     ├──────────────────┤     │
  68.     │      unused      │     │
  69.     ├──────────────────┤     │
  70.     │  OEM Identifier  │     │
  71.     │  OEM Info        │     │
  72.     │                  │     │   DOS 2.0 Section
  73.     │    Offset to     │     │   (for DOS compatibility only)
  74.     │    PE Header     │     │
  75.     ├──────────────────┤     │
  76.     │   DOS 2.0 Stub   │     │
  77.     │   Program &      │     │
  78.     │   Reloc. Table   │     │
  79.     ├──────────────────┤  <──┘
  80.     │      unused      │
  81.     ├──────────────────┤  <───────── Aligned on 8 byte boundary
  82.     │    PE Header     │
  83.     ├──────────────────┤
  84.     │   Object Table   │
  85.     ├──────────────────┤
  86.     │   Image Pages    │
  87.     │     import info  │
  88.     │     export info  │
  89.     │     fixup info   │
  90.     │     resource info│
  91.     │     debug info   │
  92.     └──────────────────┘
  93.     
  94. Figure 1. A typical 32-bit Portable EXE File Layout
  95.  
  96.  
  97.  
  98. 2. PE Header
  99.  
  100.     
  101.     ┌───────────────────────────┬─────────────┬─────────────┐
  102.     │      SIGNATURE BYTES      │  CPU TYPE   │  # OBJECTS  │
  103.     ├───────────────────────────┼─────────────┴─────────────┤
  104.     │       TIME/DATE STAMP     │         RESERVED          │
  105.     ├───────────────────────────┼─────────────┬─────────────┤
  106.     │          RESERVED         │  NT HDR SIZE│    FLAGS    │
  107.     ├─────────────┬──────┬──────┼─────────────┴─────────────┤
  108.     │  RESERVED   │LMAJOR│LMINOR│         RESERVED          │
  109.     ├─────────────┴──────┴──────┼───────────────────────────┤
  110.     │          RESERVED         │         RESERVED          │
  111.     ├───────────────────────────┼───────────────────────────┤
  112.     │       ENTRYPOINT RVA      │         RESERVED          │
  113.     ├───────────────────────────┼───────────────────────────┤
  114.     │          RESERVED         │        IMAGE BASE         │
  115.     ├───────────────────────────┼───────────────────────────┤
  116.     │       OBJECT ALIGN        │        FILE ALIGN         │
  117.     ├─────────────┬─────────────┼─────────────┬─────────────┤
  118.     │  OS MAJOR   │  OS MINOR   │USER MAJOR   │USER MINOR   │
  119.     ├─────────────┼─────────────┼─────────────┴─────────────┤
  120.     │ SUBSYS MAJOR│ SUBSYS MINOR│         RESERVED          │
  121.     ├─────────────┴─────────────┼───────────────────────────┤
  122.     │        IMAGE SIZE         │       HEADER SIZE         │
  123.     ├───────────────────────────┼─────────────┬─────────────┤
  124.     │       FILE CHECKSUM       │  SUBSYSTEM  │  DLL FLAGS  │
  125.     ├───────────────────────────┼─────────────┴─────────────┤
  126.     │   STACK RESERVE SIZE      │     STACK COMMIT SIZE     │
  127.     ├───────────────────────────┼───────────────────────────┤
  128.     │   HEAP RESERVE SIZE       │     HEAP COMMIT SIZE      │
  129.     ├───────────────────────────┼───────────────────────────┤
  130.     │         RESERVED          │  # INTERESTING RVA/SIZES  │
  131.     ├───────────────────────────┼───────────────────────────┤
  132.     │   EXPORT TABLE RVA        │   TOTAL EXPORT DATA SIZE  │
  133.     ├───────────────────────────┼───────────────────────────┤
  134.     │   IMPORT TABLE RVA        │   TOTAL IMPORT DATA SIZE  │
  135.     ├───────────────────────────┼───────────────────────────┤
  136.     │  RESOURCE TABLE RVA       │  TOTAL RESOURCE DATA SIZE │
  137.     ├───────────────────────────┼───────────────────────────┤
  138.     │  EXCEPTION TABLE RVA      │  TOTAL EXCEPTION DATA SIZE│
  139.     ├───────────────────────────┼───────────────────────────┤
  140.     │  SECURITY TABLE RVA       │  TOTAL SECURITY DATA SIZE │
  141.     ├───────────────────────────┼───────────────────────────┤
  142.     │    FIXUP TABLE RVA        │  TOTAL FIXUP DATA SIZE    │
  143.     ├───────────────────────────┼───────────────────────────┤
  144.     │    DEBUG TABLE RVA        │  TOTAL DEBUG DIRECTORIES  │
  145.     ├───────────────────────────┼───────────────────────────┤
  146.     │  IMAGE DESCRIPTION RVA    │  TOTAL DESCRIPTION SIZE   │
  147.     ├───────────────────────────┼───────────────────────────┤
  148.     │   MACHINE SPECIFIC RVA    │   MACHINE SPECIFIC SIZE   │
  149.     ├───────────────────────────┼───────────────────────────┤
  150.     │  THREAD LOCAL STORAGE RVA │      TOTAL TLS SIZE       │
  151.     └───────────────────────────┴───────────────────────────┘
  152.     
  153. Figure 2. PE Header
  154.  
  155. Notes:
  156.  
  157.   o  A VA is a virtual address that is already biased by the Image
  158.      Base found in the PE Header.  A RVA is a virtual address that is
  159.      relative to the Image Base.
  160.      
  161.   o  An RVA in the PE Header which has a value of zero indicates the
  162.      field isn't used.
  163.      
  164.   o  Image pages are aligned and zero padded to a File Align
  165.      boundary.  The bases of all other tables and structures must be
  166.      aligned on DWORD (4 byte) boundary.  Thus, all VA's and RVA's
  167.      must be on a 32 bit boundary. All table and structure fields
  168.      must be aligned on their "natural" boundaries, with the possible
  169.      exception of the Debug Info.
  170.      
  171. SIGNATURE BYTES = DB * 4.
  172. Current value is "PE/0/0". Thats PE followed by two zeros (nulls).
  173.  
  174. CPU TYPE = DW CPU Type.
  175. This field specifies the type of CPU compatibility required by this
  176. image to run.  The values are:
  177.  
  178.   o  0000h __unknown
  179.      
  180.   o  014Ch __80386
  181.      
  182.   o  014Dh __80486
  183.      
  184.   o  014Eh __80586
  185.      
  186.   o  0162h __MIPS Mark I (R2000, R3000)
  187.      
  188.   o  0163h __MIPS Mark II (R6000)
  189.      
  190.   o  0166h __MIPS Mark III (R4000)
  191.      
  192. # OBJECTS = DW Number of object entries.
  193. This field specifies the number of entries in the Object Table.
  194.  
  195. TIME/DATE STAMP = DD Used to store the time and date the file was
  196. created or modified by the linker.
  197.  
  198. NT HDR SIZE = DW This is the number of remaining bytes in the NT
  199. header that follow the FLAGS field.
  200.  
  201. FLAGS = DW Flag bits for the image.
  202. The flag bits have the following definitons:
  203.  
  204.   o  0000h __Program image.
  205.      
  206.   o  0002h __Image is executable.
  207.      If this bit isn't set, then it indicates that either errors
  208.      where detected at link time or that the image is being
  209.      incrementally linked and therefore can't be loaded.
  210.      
  211.   o  0200h __Fixed.
  212.      Indicates that if the image can't be loaded at the Image Base,
  213.      then don't load it.
  214.      
  215.   o  2000h __Library image.
  216.      
  217. LMAJOR/LMINOR = DB Linker major/minor version number.
  218.  
  219. ENTRYPOINT RVA = DD Entrypoint relative virtual address.
  220. The address is relative to the Image Base.  The address is the
  221. starting address for program images and the library initialization
  222. and library termination address for library images.
  223.  
  224. IMAGE BASE = DD The virtual base of the image.
  225. This will be the virtual address of the first byte of the file (Dos
  226. Header).  This must be a multiple of 64K.
  227.  
  228. OBJECT ALIGN = DD The alignment of the objects. This must be a power
  229. of 2 between 512 and 256M inclusive. The default is 64K.
  230.  
  231. FILE ALIGN = DD Alignment factor used to align image pages.  The
  232. alignment factor (in bytes) used to align the base of the image pages
  233. and to determine the granularity of per-object trailing zero pad.
  234. Larger alignment factors will cost more file space; smaller alignment
  235. factors will impact demand load performance, perhaps significantly.
  236. Of the two, wasting file space is preferable.  This value should be a
  237. power of 2 between 512 and 64K inclusive.
  238.  
  239. OS MAJOR/MINOR = DW OS version number required to run this image.
  240.  
  241. USER MAJOR/MINOR # = DW User major/minor version number.
  242. This is useful for differentiating between revisions of
  243. images/dynamic linked libraries.  The values are specified at link
  244. time by the user.
  245.  
  246. SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number.
  247.  
  248. IMAGE SIZE = DD The virtual size (in bytes) of the image.
  249. This includes all headers.  The total image size must be a multiple
  250. of Object Align.
  251.  
  252. HEADER SIZE = DD Total header size.
  253. The combined size of the Dos Header, PE Header and Object Table.
  254.  
  255. FILE CHECKSUM = DD Checksum for entire file.  Set to 0 by the linker.
  256.  
  257. SUBSYSTEM = DW NT Subsystem required to run this image.
  258. The values are:
  259.  
  260.   o  0000h __Unknown
  261.      
  262.   o  0001h __Native
  263.      
  264.   o  0002h __Windows GUI
  265.      
  266.   o  0003h __Windows Character
  267.      
  268.   o  0005h __OS/2 Character
  269.      
  270.   o  0007h __Posix Character
  271.      
  272. DLL FLAGS = DW Indicates special loader requirements.
  273. This flag has the following bit values:
  274.  
  275.   o  0001h __Per-Process Library Initialization.
  276.      
  277.   o  0002h __Per-Process Library Termination.
  278.      
  279.   o  0004h __Per-Thread Library Initialization.
  280.      
  281.   o  0008h __Per-Thread Library Termination.
  282.      
  283. All other bits are reserved for future use and should be set to zero.
  284.  
  285. STACK RESERVE SIZE = DD Stack size needed for image.
  286. The memory is reserved, but only the STACK COMMIT SIZE is committed.
  287. The next page of the stack is a 'guarded page'. When the application
  288. hits the guarded page, the guarded page becomes valid, and the next
  289. page becomes the guarded page. This continues until the RESERVE SIZE
  290. is reached.
  291.  
  292. STACK COMMIT SIZE = DD Stack commit size.
  293.  
  294. HEAP RESERVE SIZE = DD Size of local heap to reserve.
  295.  
  296. HEAP COMMIT SIZE = DD Amount to commit in local heap.
  297.  
  298. # INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array
  299. that follows.
  300.  
  301. EXPORT TABLE RVA = DD  Relative Virtual Address of the Export Table.
  302. This address is relative to the Image Base.
  303.  
  304. IMPORT TABLE RVA = DD  Relative Virtual Address of the Import Table.
  305. This address is relative to the Image Base.
  306.  
  307. RESOURCE TABLE RVA = DD  Relative Virtual Address of the Resource
  308. Table. This address is relative to the Image Base.
  309.  
  310. EXCEPTION TABLE RVA = DD  Relative Virtual Address of the Exception
  311. Table. This address is relative to the Image Base.
  312.  
  313. SECURITY TABLE RVA = DD  Relative Virtual Address of the Security
  314. Table. This address is relative to the Image Base.
  315.  
  316. FIXUP TABLE RVA = DD  Relative Virtual Address of the Fixup Table.
  317. This address is relative to the Image Base.
  318.  
  319. DEBUG TABLE RVA = DD  Relative Virtual Address of the Debug Table.
  320. This address is relative to the Image Base.
  321.  
  322. IMAGE DESCRIPTION RVA = DD  Relative Virtual Address of the
  323. description string specified in the module definiton file.
  324.  
  325. MACHINE SPECIFIC RVA = DD  Relative Virtual Address of a machine
  326. specific value. This address is relative to the Image Base.
  327.  
  328. TOTAL EXPORT DATA SIZE = DD  Total size of the export data.
  329.  
  330. TOTAL IMPORT DATA SIZE = DD  Total size of the import data.
  331.  
  332. TOTAL RESOURCE DATA SIZE = DD  Total size of the resource data.
  333.  
  334. TOTAL EXCEPTION DATA SIZE = DD  Total size of the exception data.
  335.  
  336. TOTAL SECURITY DATA SIZE = DD  Total size of the security data.
  337.  
  338. TOTAL FIXUP DATA SIZE = DD  Total size of the fixup data.
  339.  
  340. TOTAL DEBUG DIRECTORIES = DD  Total number of debug directories.
  341.  
  342. TOTAL DESCRIPTION SIZE = DD  Total size of the description data.
  343.  
  344. MACHINE SPECIFIC SIZE = DD  A machine specific value.
  345.  
  346.  
  347.  
  348. 3. Object Table
  349.  
  350. The number of entries in the Object Table is given by the # Objects
  351. field in the PE Header.  Entries in the Object Table are numbered
  352. starting from one.  The object table immediately follows the PE
  353. Header.  The code and data memory object entries are in the order
  354. chosen by the linker.  The virtual addresses for objects must be
  355. assigned by the linker such that they are in ascending order and
  356. adjacent, and must be a multiple of Object Align in the PE header.
  357.  
  358. Each Object Table entry has the following format:
  359.  
  360.     ┌───────────────────────────────────────────────────────┐
  361.     │                     OBJECT NAME                       │
  362.     ├───────────────────────────┬───────────────────────────┤
  363.     │       VIRTUAL SIZE        │           RVA             │
  364.     ├───────────────────────────┼───────────────────────────┤
  365.     │      PHYSICAL SIZE        │      PHYSICAL OFFSET      │
  366.     ├───────────────────────────┼───────────────────────────┤
  367.     │        RESERVED           │         RESERVED          │
  368.     ├───────────────────────────┼───────────────────────────┤
  369.     │        RESERVED           │       OBJECT FLAGS        │
  370.     └───────────────────────────┴───────────────────────────┘
  371.     
  372. Figure 3.  Object Table
  373.  
  374. OBJECT NAME = DB * 8  Object name. This is an eight-byte null-padded
  375. ASCII string representing the object name.
  376.  
  377. VIRTUAL SIZE = DD Virtual memory size.  The size of the object that
  378. will be allocated when the object is loaded. Any difference between
  379. PHYSICAL SIZE and VIRTUAL SIZE is zero filled.
  380.  
  381. RVA = DD Relative Virtual Address.  The virtual address the object is
  382. currently relocated to, relative to the Image Base.  Each Object's
  383. virtual address space consumes a multiple of Object Align (power of 2
  384. between 512 and 256M inclusive. Default is 64K), and immediately
  385. follows the previous Object in the virtual address space (the virtual
  386. address space for a image must be dense).
  387.  
  388. PHYSICAL SIZE = DD Physical file size of initialized data.  The size
  389. of the initialized data in the file for the object.  The physical
  390. size must be a multiple of the File Align field in the PE Header, and
  391. must be less than or equal to the Virtual Size.
  392.  
  393. PHYSICAL OFFSET = DD Physical offset for object's first page.  This
  394. offset is relative to beginning of the EXE file, and is aligned on a
  395. multiple of the File Align field in the PE Header.  The offset is
  396. used as a seek value.
  397.  
  398. OBJECT FLAGS = DD Flag bits for the object.  The object flag bits
  399. have the following definitions:
  400.  
  401.   o  000000020h __Code object.
  402.      
  403.   o  000000040h __Initialized data object.
  404.      
  405.   o  000000080h __Uninitialized data object.
  406.      
  407.   o  040000000h __Object must not be cached.
  408.      
  409.   o  080000000h __Object is not pageable.
  410.      
  411.   o  100000000h __Object is shared.
  412.      
  413.   o  200000000h __Executable object.
  414.      
  415.   o  400000000h __Readable object.
  416.      
  417.   o  800000000h __Writeable object.
  418.      
  419. All other bits are reserved for future use and should be set to zero.
  420.  
  421. 4. Image Pages
  422.  
  423. The Image Pages section contains all initialized data for all
  424. objects.  The seek offset for the first page in each object is
  425. specified in the object table and is aligned on a File Align
  426. boundary.  The objects are ordered by the RVA.  Every object begins
  427. on a multiple of Object Align.
  428.  
  429.  
  430.  
  431. 5. Exports
  432.  
  433. A typical file layout for the export information follows:
  434.  
  435.     ┌───────────────────────┐
  436.     │     DIRECTORY TABLE   │
  437.     ├───────────────────────┤
  438.     │     ADDRESS TABLE     │
  439.     │                       │
  440.     │                       │
  441.     │                       │
  442.     │                       │
  443.     │                       │
  444.     │                       │
  445.     ├───────────────────────┤
  446.     │     NAME PTR TABLE    │
  447.     │                       │
  448.     │                       │
  449.     │                       │
  450.     ├───────────────────────┤
  451.     │     ORDINAL TABLE     │
  452.     │                       │
  453.     │                       │
  454.     │                       │
  455.     ├───────────────────────┤
  456.     │     NAME STRINGS      │
  457.     │                       │
  458.     │                       │
  459.     └───────────────────────┘
  460.     
  461. Figure 4.  Export File Layout
  462.  
  463. 5.1 Export Directory Table
  464.  
  465. The export information begins with the Export Directory Table which
  466. describes the remainder of the export information.  The Export
  467. Directory Table contains address information that is used to resolve
  468. fixup references to the entry points within this image.
  469.  
  470.     ┌───────────────────────────────────┐
  471.     │            EXPORT FLAGS           │
  472.     ├───────────────────────────────────┤
  473.     │           TIME/DATE STAMP         │
  474.     ├─────────────────┬─────────────────┤
  475.     │  MAJOR VERSION  │   MINOR VERSION │
  476.     ├─────────────────┴─────────────────┤
  477.     │             NAME RVA              │
  478.     ├───────────────────────────────────┤
  479.     │           ORDINAL BASE            │
  480.     ├───────────────────────────────────┤
  481.     │           # EAT ENTRIES           │
  482.     ├───────────────────────────────────┤
  483.     │            # NAME PTRS            │
  484.     ├───────────────────────────────────┤
  485.     │         ADDRESS TABLE RVA         │
  486.     ├───────────────────────────────────┤
  487.     │        NAME PTR TABLE RVA         │
  488.     ├───────────────────────────────────┤
  489.     │         ORDINAL TABLE RVA         │
  490.     └───────────────────────────────────┘
  491.     
  492. Figure 5.  Export Directory Table Entry
  493.  
  494. EXPORT FLAGS = DD Currently set to zero.
  495.  
  496. TIME/DATE STAMP = DD Time/Date the export data was created.
  497.  
  498. MAJOR/MINOR VERSION = DW  A user settable major/minor version number.
  499.  
  500. NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
  501. This is the address relative to the Image Base.
  502.  
  503. ORDINAL BASE = DD First valid exported ordinal.
  504. This field specifies the starting ordinal number for the export
  505. address table for this image.  Normally set to 1.
  506.  
  507. # EAT ENTRIES = DD Indicates number of entries in the Export Address
  508. Table.
  509.  
  510. # NAME PTRS = DD This indicates the number of entries in the Name Ptr
  511. Table (and parallel Ordinal Table).
  512.  
  513. ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address
  514. Table.
  515. This address is relative to the Image Base.
  516.  
  517. NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table
  518. Pointers.
  519. This address is relative to the beginning of the Image Base.  This
  520. table is an array of RVA's with # NAMES entries.
  521.  
  522. ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals
  523. Table Entry.
  524. This address is relative to the beginning of the Image Base.
  525.  
  526. 5.2 Export Address Table
  527.  
  528. The Export Address Table contains the address of exported entrypoints
  529. and exported data and absolutes.  An ordinal number is used to index
  530. the Export Address Table. The ORDINAL BASE must be subracted from the
  531. ordinal number before indexing into this table.
  532.  
  533. Export Address Table entry formats are described below:
  534.  
  535.     ┌────────┬────────┬────────┬────────┐
  536.     │           EXPORTED RVA            │
  537.     └────────┴────────┴────────┴────────┘
  538.     
  539. Figure 6.  Export Address Table Entry
  540.  
  541. EXPORTED RVA = DD Export address.
  542. This field contains the relative virtual address of the exported
  543. entry (relative to the Image Base).
  544.  
  545. 5.3 Export Name Table Pointers
  546.  
  547. The export name table pointers array contains address into the Export
  548. Name Table.  The pointers are 32-bits each, and are relative to the
  549. Image Base.  The pointers are ordered lexically to allow binary
  550. searches.
  551.  
  552. 5.4 Export Ordinal Table
  553.  
  554. The Export Name Table Pointers and the Export Ordinal Table form two
  555. parallel arrays, separated to allow natural field alignment.  The
  556. export ordinal table array contains the Export Address Table ordinal
  557. numbers associated with the named export referenced by corresponding
  558. Export Name Table Pointers.
  559.  
  560. The ordinals are 16-bits each, and already include the Ordinal Base
  561. stored in the Export Directory Table.
  562.  
  563. 5.5 Export Name Table
  564.  
  565. The export name table contains optional ASCII names for exported
  566. entries in the image.  These tables are used with the array of Export
  567. Name Table Pointers and the array of Export Ordinals to translate a
  568. procedure name string into an ordinal number by searching for a
  569. matching name string.  The ordinal number is used to locate the entry
  570. point information in the export address table.
  571.  
  572. Import references by name require the Export Name Table Pointers
  573. table to be binary searched to find the matching name, then the
  574. corresponding Export Ordinal Table is known to contain the entry
  575. point ordinal number.  Import references by ordinal number provide
  576. the fastest lookup since searching the name table is not required.
  577.  
  578. Each name table entry has the following format:
  579.  
  580.     ┌────────┬────────┬────────┬────────┐
  581.     │ ASCII STRING ::: ::::::::   '\0'  │
  582.     └────────┴────────┴────────┴────────┘
  583.     
  584. Figure 7.  Export Name Table Entry
  585.  
  586. ASCII STRING = DB ASCII String.
  587. The string is case sensitive and is terminated by a null byte.
  588.  
  589.  
  590.  
  591. 6. Imports
  592.  
  593. A typical file layout for the import information follows:
  594.  
  595.     ┌───────────────────────┐
  596.     │     DIRECTORY TABLE   │
  597.     │                       │
  598.     │                       │
  599.     │                       │
  600.     ├───────────────────────┤
  601.     │    NULL DIR ENTRY     │
  602.     └───────────────────────┘
  603.     
  604.     ┌───────────────────────┐
  605.     │   DLL1 LOOKUP TABLE   │
  606.     │                       │
  607.     ├───────────────────────┤
  608.     │         NULL          │
  609.     └───────────────────────┘
  610.     
  611.     ┌───────────────────────┐
  612.     │   DLL2 LOOKUP TABLE   │
  613.     │                       │
  614.     ├───────────────────────┤
  615.     │         NULL          │
  616.     └───────────────────────┘
  617.     
  618.     ┌───────────────────────┐
  619.     │   Dll3 LOOKUP TABLE   │
  620.     │                       │
  621.     ├───────────────────────┤
  622.     │         NULL          │
  623.     └───────────────────────┘
  624.     
  625.     ┌───────────────────────┐
  626.     │    HINT-NAME TABLE    │
  627.     │                       │
  628.     └───────────────────────┘
  629.     
  630.     ┌───────────────────────┐
  631.     │   DLL1 ADDRESS TABLE  │
  632.     │                       │
  633.     ├───────────────────────┤
  634.     │         NULL          │
  635.     └───────────────────────┘
  636.     
  637.     ┌───────────────────────┐
  638.     │   DLL2 ADDRESS TABLE  │
  639.     │                       │
  640.     ├───────────────────────┤
  641.     │         NULL          │
  642.     └───────────────────────┘
  643.     
  644.     ┌───────────────────────┐
  645.     │   DLL3 ADDRESS TABLE  │
  646.     │                       │
  647.     ├───────────────────────┤
  648.     │         NULL          │
  649.     └───────────────────────┘
  650.     
  651. Figure 8.  Import File Layout
  652.  
  653. 6.1 Import Directory Table
  654.  
  655. The import information begins with the Import Directory Table which
  656. describes the remainder of the import information.  The Import
  657. Directory Table contains address information that is used to resolve
  658. fixup references to the entry points within a DLL image.  The import
  659. directory table consists of an array of Import Directory Entries, one
  660. entry for each DLL this image references. The last directory entry is
  661. empty (NULL) which indicates the end of the directory table.
  662.  
  663. An Import Directory Entry has the following format:
  664.  
  665.     ┌────────┬────────┬────────┬────────┐
  666.     │            IMPORT FLAGS           │
  667.     ├───────────────────────────────────┤
  668.     │           TIME/DATE STAMP         │
  669.     ├─────────────────┬─────────────────┤
  670.     │  MAJOR VERSION  │   MINOR VERSION │
  671.     ├─────────────────┴─────────────────┤
  672.     │              NAME RVA             │
  673.     ├───────────────────────────────────┤
  674.     │      IMPORT LOOKUP TABLE RVA      │
  675.     ├───────────────────────────────────┤
  676.     │      IMPORT ADDRESS TABLE RVA     │
  677.     └────────┴────────┴────────┴────────┘
  678.     
  679. Figure 9.  Import Directory Entry
  680.  
  681. IMPORT FLAGS = DD Currently set to zero.
  682.  
  683. TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or
  684. zero if not pre-snapped.
  685.  
  686. MAJOR/MINOR VERSION = DW  The major/minor version number of the dll
  687. being referenced.
  688.  
  689. NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
  690. This is the address relative to the Image Base.
  691.  
  692. IMPORT LOOKUP TABLE RVA = DD This field contains the address of the
  693. start of the import lookup table for this image.  The address is
  694. relative to the beginning of the Image Base.
  695.  
  696. IMPORT ADDRESS TABLE RVA = DD This field contains the address of the
  697. start of the import addresses for this image.  The address is
  698. relative to the beginning of the Image Base.
  699.  
  700. 6.2 Import Lookup Table
  701.  
  702. The Import Lookup Table is an array of ordinal or hint/name RVA's for
  703. each DLL. The last entry is empty (NULL) which indicates the end of
  704. the table.
  705.  
  706. The last element is empty.
  707.  
  708.      3                                 0
  709.      1
  710.     ┌─╥──────┬────────┬────────┬────────┐
  711.     │0║   ORDINAL#/HINT-NAME TABLE RVA  │
  712.     └─╨──────┴────────┴────────┴────────┘
  713.     
  714. Figure 10.  Import Address Table Format
  715.  
  716. ORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal
  717. Number or Name Table RVA.
  718. If the import is by ordinal, this field contains a 31 bit ordinal
  719. number.  If the import is by name, this field contains a 31 bit
  720. address relative to the Image Base to the Hint-Name Table.
  721.  
  722. O = 1-bit (mask = 80000000h) Import by ordinal flag.
  723.  
  724.   o  00000000h __Import by name.
  725.      
  726.   o  80000000h __Import by ordinal.
  727.      
  728. 6.3 Hint-Name Table
  729.  
  730. The Hint-Name Table format follows:
  731.  
  732.     ┌────────┬────────┬────────┬────────┐
  733.     │       HINT      │ ASCII STRING |||│
  734.     ├────────┼────────┼────────┼────────┤
  735.     │|||||||||||||||||│  '\0'     PAD   │
  736.     └────────┴────────┴────────┴────────┘
  737.     
  738.     
  739.     The PAD field is optional.
  740.     
  741. Figure 11.  Import Hint-Name Table
  742.  
  743. HINT = DW Hint into Export Name Table Pointers.
  744. The hint value is used to index the Export Name Table Pointers array,
  745. allowing faster by-name imports.  If the hint is incorrect, then a
  746. binary search is performed on the Export Name Ptr Table.
  747.  
  748. ASCII STRING = DB ASCII String.
  749. The string is case sensitive and is terminated by a null byte.
  750.  
  751. PAD = DB Zero pad byte.
  752. A trailing zero pad byte appears after the trailing null byte if
  753. necessary to align the next entry on an even boundary.
  754.  
  755. The loader overwrites the import address table when loading the image
  756. with the 32-bit address of the import.
  757.  
  758.  
  759.  
  760. 6.4 Import Address Table
  761.  
  762. The Import Address Table is an array of addresses of the imported
  763. routines for each DLL. The last entry is empty (NULL) which indicates
  764. the end of the table.
  765.  
  766. 7. Thread Local Storage
  767.  
  768. Thread local storage is a special contiguous block of data. Each
  769. thread will gets its own block upon creation of the thread.
  770.  
  771. The file layout for thread local storage follows:
  772.     ┌───────────────────────┐
  773.     │     DIRECTORY TABLE   │
  774.     └───────────────────────┘
  775.     ┌───────────────────────┐
  776.     │        TLS DATA       │
  777.     └───────────────────────┘
  778.     ┌───────────────────────┐
  779.     │      INDEX VARIABLE   │
  780.     └───────────────────────┘
  781.     ┌───────────────────────┐
  782.     │   CALLBACK ADDRESSES  │
  783.     └───────────────────────┘
  784.  
  785. Figure 12.  Thread Local Storage Layout
  786.  
  787. 7.1 Thread Local Storage Directory Table
  788.  
  789. The Thread Local Storage Directory Table contains address information
  790. that is used to describe the rest of TLS.
  791.  
  792. The Thread Local Storage Directory Table has the following format:
  793.  
  794.     ┌────────┬────────┬────────┬────────┐
  795.     │       START DATA BLOCK VA         │
  796.     ├───────────────────────────────────┤
  797.     │        END DATA BLOCK VA          │
  798.     ├───────────────────────────────────┤
  799.     │             INDEX VA              │
  800.     ├───────────────────────────────────┤
  801.     │         CALLBACK TABLE VA         │
  802.     └────────┴────────┴────────┴────────┘
  803.     
  804. Figure 13.  Thread Local Storage Directory Table
  805.  
  806. START DATA BLOCK VA = DD Virtual Address of the start of the thread
  807. local storage data block.
  808.  
  809. END DATA BLOCK VA = DD Virtual Address of the end of the thread local
  810. storage data block.
  811.  
  812. INDEX VA = DD  Virtual Address of the index variable used to access
  813. the thread local storage data block.
  814.  
  815. CALLBACK TABLE VA = DD Virtual Address of the callback table.
  816.  
  817. 7.2 Thread Local Storage CallBack Table
  818.  
  819. The Thread Local Storage Callbacks is an array of Virtual Address of
  820. functions to be called by the loader after thread creation and thread
  821. termination. The last entry is empty (NULL) which indicates the end
  822. of the table.
  823.  
  824. The Thread Local Storage CallBack Table has the following format:
  825.  
  826.     ┌────────┬────────┬────────┬────────┐
  827.     │            FUNCTION1 VA           │
  828.     ├───────────────────────────────────┤
  829.     │            FUNCTION2 VA           │
  830.     ├───────────────────────────────────┤
  831.     │                                   │
  832.     ├───────────────────────────────────┤
  833.     │                NULL               │
  834.     └────────┴────────┴────────┴────────┘
  835.     
  836. Figure 14.  Thread Local Storage CallBack Table
  837.  
  838. 8. Resources
  839.  
  840. Resources are indexed by a multiple level binary-sorted tree
  841. structure.  The overall design can incorporate 2**31 levels, however,
  842. NT uses only three:  the highest is TYPE, then NAME, then LANGUAGE.
  843.  
  844. A typical file layout for the resource information follows:
  845.     ┌───────────────────────┐
  846.     │  RESOURCE DIRECTORY   │
  847.     │                       │
  848.     │                       │
  849.     │                       │
  850.     ├───────────────────────┤
  851.     │     RESOURCE DATA     │
  852.     │                       │
  853.     │                       │
  854.     │                       │
  855.     │                       │
  856.     │                       │
  857.     │                       │
  858.     └───────────────────────┘
  859.     
  860. Figure 15.  Resource File Layout
  861.  
  862.  
  863. The Resource directory is made up of the following tables:
  864.  
  865.  
  866.  
  867. 8.1 Resource Directory Table
  868. ┌────────┬────────┬────────┬────────┐
  869. │           RESOURCE FLAGS          │
  870. ├───────────────────────────────────┤
  871. │           TIME/DATE STAMP         │
  872. ├─────────────────┬─────────────────┤
  873. │  MAJOR VERSION  │   MINOR VERSION │
  874. ├─────────────────┼─────────────────┤
  875. │    # NAME ENTRY │  # ID ENTRY     │
  876. ├─────────────────┴─────────────────┤
  877. │       RESOURCE DIR ENTRIES        │
  878. └────────┴────────┴────────┴────────┘
  879.  
  880. Figure 16.  Resource Table Entry
  881.  
  882.  
  883. RESOURCE FLAGS = DD Currently set to zero.
  884.  
  885. TIME/DATE  STAMP = DD Time/Date the resource data was created by the
  886. resource compiler.
  887.  
  888. MAJOR/MINOR VERSION = DW  A user settable major/minor version number.
  889.  
  890. # NAME ENTRY = DW The number of name entries.
  891. This field contains the number of entries at the beginning of the
  892. array of directory entries which have actual string names associated
  893. with them.
  894.  
  895. # ID ENTRY = DW The number of ID integer entries.
  896. This field contains the number of 32-bit integer IDs as their names
  897. in the array of directory entries.
  898.  
  899. The resource directory is followed by a variable length array of
  900. directory entries.  # NAME ENTRY is the number of entries at the
  901. beginning of the array that have actual names associated with each
  902. entry.  The entires are in ascending order, case insensitive strings.
  903. # ID ENTRY identifies the number of entries that have 32-bit integer
  904. IDs as their name.  These entries are also sorted in ascending order.
  905.  
  906. This structure allows fast lookup by either name or number, but for
  907. any given resource entry only one form of lookup is supported, not
  908. both. This is consistent with the syntax of the .RC file and the .RES
  909. file.
  910.  
  911.  
  912.  
  913. The array of directory entries have the following format:
  914.  3                                 0
  915.  1
  916. ┌────────┬────────┬────────┬────────┐
  917. │         NAME RVA/INTEGER ID       │
  918. ├─╥─────────────────────────────────┤
  919. │E║     DATA ENTRY RVA/SUBDIR RVA   │
  920. └─╨──────┴────────┴────────┴────────┘
  921.  
  922. Figure 17.  Resource Directory Entry
  923.  
  924.  
  925. INTERGER ID = DD ID.
  926. This field contains a integer ID field to identify a resource.
  927.  
  928. NAME RVA = DD Name RVA address.
  929. This field contains a 31-bit address relative to the beginning of the
  930. Image Base to a Resource Directory String Entry.
  931.  
  932. E = 1-bit (mask 80000000h) Unescape bit.
  933. This bit is zero for unescaped Resource Data Entries.
  934.  
  935. DATA RVA = 31-bits (mask 7fffffffh) Data entry address.
  936. This field contains a 31-bit address relative to the beginning of the
  937. Image Base to a Resource Data Entry.
  938.  
  939. E = 1-bit (mask 80000000h) Escape bit.
  940. This bit is 1 for escaped Subdirectory Entry.
  941.  
  942. DATA RVA = 31-bits (mask 7fffffffh) Directory entries.
  943. This field contains a 31-bit address relative to the beginning of the
  944. Image Base to Subdirectory Entry.
  945.  
  946.  
  947.  
  948. Each resource directory string entry has the following format:
  949. ┌────────┬────────┬────────┬────────┐
  950. │      LENGTH     │ UNICODE STRING  │
  951. ├────────┼────────┼────────┼────────┤
  952. │                                   │
  953. └────────┴────────┴────────┴────────┘
  954.  
  955. Figure 18.  Resource Directory String Entry
  956.  
  957.  
  958. LENGTH = DW Length of string.
  959.  
  960. UNICODE STRING = DW UNICODE String.
  961.  
  962. All of these string objects are stored together after the last
  963. resource directory entry and before the first resource data object.
  964. This minimizes the impact of these variable length objects on the
  965. alignment of the fixed size directory entry objects. The length needs
  966. to be word aligned.
  967.  
  968.  
  969.  
  970. Each Resource Data Entry has the following format:
  971.  
  972.     ┌────────┬────────┬────────┬────────┐
  973.     │              DATA RVA             │
  974.     ├───────────────────────────────────┤
  975.     │               SIZE                │
  976.     ├───────────────────────────────────┤
  977.     │              CODEPAGE             │
  978.     ├───────────────────────────────────┤
  979.     │              RESERVED             │
  980.     └────────┴────────┴────────┴────────┘
  981.     
  982. Figure 19.  Resource Data Entry
  983.  
  984.  
  985.  
  986. DATA RVA = DD Address of Resource Data.
  987. This field contains 32-bit virtaul address of the resource data
  988. (relative to the Image Base).
  989.  
  990. SIZE = DD Size of Resource Data.
  991. This field contains the size of the resource data for this resource.
  992.  
  993. CODEPAGE = DD Codepage.
  994.  
  995. RESERVED = DD Reserved - must be zero.
  996.  
  997. Each resource data entry describes a leaf node in the resource
  998. directory tree.  It contains an address which is  relative to the
  999. beginning of Image Base, a size field that gives the number of bytes
  1000. of data at that address, a CodePage that should be used when decoding
  1001. code point values within the resource data.  Typically for new
  1002. applications the code page would be the unicode code page.
  1003.  
  1004.  
  1005.  
  1006. 8.2 Resource Example
  1007.  
  1008. The following is an example for an app. which wants to use the following data
  1009. as resources:
  1010.  
  1011.   TypeId#    NameId#   Language ID Resource Data
  1012.  00000001    00000001       0        00010001
  1013.  00000001    00000001       1        10010001
  1014.  00000001    00000002       0        00010002
  1015.  00000001    00000003       0        00010003
  1016.  00000002    00000001       0        00020001
  1017.  00000002    00000002       0        00020002
  1018.  00000002    00000003       0        00020003
  1019.  00000002    00000004       0        00020004
  1020.  00000009    00000001       0        00090001
  1021.  00000009    00000009       0        00090009
  1022.  00000009    00000009       1        10090009
  1023.  00000009    00000009       2        20090009
  1024.  
  1025. Then the Resource Directory in the Portable format looks like:
  1026. Offset         Data
  1027. 0000:   00000000 00000000 00000000 00030000  (3 entries in this directory)
  1028. 0010:   00000001 80000028     (TypeId #1, Subdirectory at offset 0x28)
  1029. 0018:   00000002 80000050     (TypeId #2, Subdirectory at offset 0x50)
  1030. 0020:   00000009 80000080     (TypeId #9, Subdirectory at offset 0x80)
  1031. 0028:   00000000 00000000 00000000 00030000  (3 entries in this directory)
  1032. 0038:   00000001 800000A0     (NameId #1, Subdirectory at offset 0xA0)
  1033. 0040:   00000002 00000108     (NameId #2, data desc at offset 0x108)
  1034. 0048:   00000003 00000118     (NameId #3, data desc at offset 0x118)
  1035. 0050:   00000000 00000000 00000000 00040000  (4 entries in this directory)
  1036. 0060:   00000001 00000128     (NameId #1, data desc at offset 0x128)
  1037. 0068:   00000002 00000138     (NameId #2, data desc at offset 0x138)
  1038. 0070:   00000003 00000148     (NameId #3, data desc at offset 0x148)
  1039. 0078:   00000004 00000158     (NameId #4, data desc at offset 0x158)
  1040. 0080:   00000000 00000000 00000000 00020000  (2 entries in this directory)
  1041. 0090:   00000001 00000168     (NameId #1, data desc at offset 0x168)
  1042. 0098:   00000009 800000C0     (NameId #9, Subdirectory at offset 0xC0)
  1043. 00A0:   00000000 00000000 00000000 00020000  (2 entries in this directory)
  1044. 00B0:   00000000 000000E8     (Language ID 0, data desc at offset 0xE8
  1045. 00B8:   00000001 000000F8     (Language ID 1, data desc at offset 0xF8
  1046. 00C0:   00000000 00000000 00000000 00030000  (3 entries in this directory)
  1047. 00D0:   00000001 00000178     (Language ID 0, data desc at offset 0x178
  1048. 00D8:   00000001 00000188     (Language ID 1, data desc at offset 0x188
  1049. 00E0:   00000001 00000198     (Language ID 2, data desc at offset 0x198
  1050.  
  1051. 00E8:   000001A8  (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0
  1052.         00000004  (4 bytes of data)
  1053.         00000000  (codepage)
  1054.         00000000  (reserved)
  1055. 00F8:   000001AC  (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1
  1056.         00000004  (4 bytes of data)
  1057.         00000000  (codepage)
  1058.         00000000  (reserved)
  1059. 0108:   000001B0  (At offset 0x1B0, for TypeId #1, NameId #2,
  1060.         00000004  (4 bytes of data)
  1061.         00000000  (codepage)
  1062.         00000000  (reserved)
  1063. 0118:   000001B4  (At offset 0x1B4, for TypeId #1, NameId #3,
  1064.         00000004  (4 bytes of data)
  1065.         00000000  (codepage)
  1066.         00000000  (reserved)
  1067. 0128:   000001B8  (At offset 0x1B8, for TypeId #2, NameId #1,
  1068.         00000004  (4 bytes of data)
  1069.         00000000  (codepage)
  1070.         00000000  (reserved)
  1071. 0138:   000001BC  (At offset 0x1BC, for TypeId #2, NameId #2,
  1072.         00000004  (4 bytes of data)
  1073.         00000000  (codepage)
  1074.         00000000  (reserved)
  1075. 0148:   000001C0  (At offset 0x1C0, for TypeId #2, NameId #3,
  1076.         00000004  (4 bytes of data)
  1077.         00000000  (codepage)
  1078.         00000000  (reserved)
  1079. 0158:   000001C4  (At offset 0x1C4, for TypeId #2, NameId #4,
  1080.         00000004  (4 bytes of data)
  1081.         00000000  (codepage)
  1082.         00000000  (reserved)
  1083. 0168:   000001C8  (At offset 0x1C8, for TypeId #9, NameId #1,
  1084.         00000004  (4 bytes of data)
  1085.         00000000  (codepage)
  1086.         00000000  (reserved)
  1087. 0178:   000001CC  (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0
  1088.         00000004  (4 bytes of data)
  1089.         00000000  (codepage)
  1090.         00000000  (reserved)
  1091. 0188:   000001D0  (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1
  1092.         00000004  (4 bytes of data)
  1093.         00000000  (codepage)
  1094.         00000000  (reserved)
  1095. 0198:   000001D4  (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2
  1096.         00000004  (4 bytes of data)
  1097.         00000000  (codepage)
  1098.         00000000  (reserved)
  1099.  
  1100. And the data for the resources will look like:
  1101. 01A8:          00010001
  1102. 01AC:          10010001
  1103. 01B0:          00010002
  1104. 01B4:          00010003
  1105. 01B8:          00020001
  1106. 01BC:          00020002
  1107. 01C0:          00020003
  1108. 01C4:          00020004
  1109. 01C8:          00090001
  1110. 01CC:          00090009
  1111. 01D0:          10090009
  1112. 01D4:          20090009
  1113.  
  1114.  
  1115. 9. Fixup Table
  1116.  
  1117. The Fixup Table contains entries for all fixups in the image. The
  1118. Total Fixup Data Size in the PE Header is the number of bytes in the
  1119. fixup table. The fixup table is broken into blocks of fixups. Each
  1120. block represents the fixups for a 4K page.
  1121.  
  1122. Fixups that are resolved by the linker do not need to be processed by
  1123. the loader, unless the load image can't be loaded at the Image Base
  1124. specified in the PE Header.
  1125.  
  1126. 9.1 Fixup Block
  1127.  
  1128. Fixup blocks have the following format:
  1129.  
  1130.     ┌───────────────────────────────────┐
  1131.     │             PAGE RVA              │
  1132.     ├───────────────────────────────────┤
  1133.     │            BLOCK SIZE             │
  1134.     ├─────────────────┬─────────────────┤
  1135.     │   TYPE/OFFSET   │   TYPE/OFFSET   │
  1136.     ├─────────────────┼─────────────────┤
  1137.     │   TYPE/OFFSET   │       ...       │
  1138.     └─────────────────┴─────────────────┘
  1139.     
  1140. Figure 20.  Fixup Block Format
  1141.  
  1142. To apply a fixup, a delta needs to be calculated.  The 32-bit delta
  1143. is the difference between the preferred base, and the base where the
  1144. image is actually loaded.  If the image is loaded at its preferred
  1145. base, the delta would be zero, and thus the fixups would not have to
  1146. be applied. Each block must start on a DWORD boundary. The ABSOLUTE
  1147. fixup type can be used to pad a block.
  1148.  
  1149. PAGE RVA = DD Page RVA. The image base plus the page rva is added to
  1150. each offset to create the virtual address of where the fixup needs to
  1151. be applied.
  1152.  
  1153. BLOCK SIZE = DD Number of bytes in the fixup block. This includes the
  1154. PAGE RVA and SIZE fields.
  1155.  
  1156. TYPE/OFFSET is defined as:
  1157.  
  1158.      1    1          0
  1159.      5    1
  1160.     ┌────╥────────────┐
  1161.     │TYPE║   OFFSET   │
  1162.     └────╨────────────┘
  1163. Figure 21.  Fixup Record Format
  1164.  
  1165. TYPE = 4-bit fixup type. This value has the following definitions:
  1166.  
  1167.   o  0h __ABSOLUTE. This is a NOP. The fixup is skipped.
  1168.      
  1169.   o  1h __HIGH. Add the high 16-bits of the delta to the 16-bit field
  1170.      at Offset.  The 16-bit field represents the high value of a 32-
  1171.      bit word.
  1172.      
  1173.   o  2h __LOW. Add the low 16-bits of the delta to the 16-bit field
  1174.      at Offset.  The 16-bit field represents the low half value of a
  1175.      32-bit word.  This fixup will only be emitted for a RISC machine
  1176.      when the image Object Align isn't the default of 64K.
  1177.      
  1178.   o  3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at
  1179.      Offset.
  1180.      
  1181.   o  4h __HIGHADJUST. This fixup requires a full 32-bit value.  The
  1182.      high 16-bits is located at Offset, and the low 16-bits is
  1183.      located in the next Offset array element (this array element is
  1184.      included in the SIZE field). The two need to be combined into a
  1185.      signed variable.  Add the 32-bit delta.  Then add 0x8000 and
  1186.      store the high 16-bits of the signed variable to the 16-bit
  1187.      field at Offset.
  1188.      
  1189.   o  5h __MIPSJMPADDR.
  1190.      
  1191. All other values are reserved.
  1192.  
  1193.  
  1194.  
  1195. 10. Debug Information
  1196.  
  1197. The debug information is defined by the debugger and is not
  1198. controlled by the portable EXE format or linker.  The only data
  1199. defined by the portable EXE format is the Debug Directory Table.
  1200.  
  1201. 10.1 Debug Directory
  1202.  
  1203. The debug directory table consists of one or more entries that have
  1204. the following format:
  1205.  
  1206.     ┌────────┬────────┬────────┬────────┐
  1207.     │            DEBUG FLAGS            │
  1208.     ├───────────────────────────────────┤
  1209.     │           TIME/DATE STAMP         │
  1210.     ├─────────────────┬─────────────────┤
  1211.     │  MAJOR VERSION  │  MINOR VERSION  │
  1212.     ├─────────────────┴─────────────────┤
  1213.     │             DEBUG TYPE            │
  1214.     ├───────────────────────────────────┤
  1215.     │             DATA SIZE             │
  1216.     ├───────────────────────────────────┤
  1217.     │             DATA RVA              │
  1218.     ├───────────────────────────────────┤
  1219.     │             DATA SEEK             │
  1220.     └────────┴────────┴────────┴────────┘
  1221.     
  1222. Figure 22.  Debug Directory Entry
  1223.  
  1224. DEBUG FLAGS = DD Set to zero for now.
  1225.  
  1226. TIME/DATE STAMP = DD Time/Date the debug data was created.
  1227.  
  1228. MAJOR/MINOR VERSION = DW Version stamp.
  1229. This stamp can be used to determine the version of the debug data.
  1230.  
  1231. DEBUG TYPE = DD Format type.
  1232. To support multiple debuggers, this field determines the format of
  1233. the debug information. This value has the following definitions:
  1234.  
  1235.   o  0001h __Image contains COFF symbolics.
  1236.      
  1237.   o  0001h __Image contains CodeView symbolics.
  1238.      
  1239.   o  0001h __Image contains FPO symbolics.
  1240.      
  1241. DATA SIZE = DD The number of bytes in the debug data. This is the
  1242. size of the actual debug data and does not include the debug
  1243. directory.
  1244.  
  1245. DATA RVA = DD The relative virtual address of the debug data. This
  1246. address is relative to the beginning of the Image Base.
  1247.  
  1248. DATA SEEK = DD The seek value from the beginning of the file to the
  1249. debug data.
  1250.  
  1251. If the image contains more than one type of debug information, then
  1252. the next debug directory will immediately follow the first debug
  1253. directory.
  1254.